A reflector can invite connections by publishing its existence on one or more directory servers. See the ``Look Who's Listening'' section in the sfspeaker manual page for details on how to set the environment variables.
Users of Speak Freely for Windows can join a conference simply by opening a new connection window and entering the reflector's hostname:port. Speak Freely for Windows automatically listens for packets on all ports to which is has open connections.
sfreflect works by simple packet replication; sound packets received from any user connected to the reflector are immediately resent, unmodified, to all other parties to the conference (but not to the originator), with whatever protocol, compression, and encryption modes were selected by the sender. This has several consequences you need to be aware of in order to run a successful conference. First of all, the site running the reflector needs to have sufficient bandwidth in its connection to the Internet backbone to permit sending a copy of every packet received to each member in the conference. For example, suppose you routinely use GSM compression to communicate over a 28.8 Kb dial-up link to your Internet Service Provider, having no bandwidth problems because GSM compression uses only slightly more than half of your available bandwidth. If you attempted to run sfreflect and had three parties in the conference, performance would be marginal since each packet received would have to be sent to the other two people, and that would exceed the capacity of the 28.8 Kb line. To avoid lost packets (at least with long individual transmissions) you'd need a faster modem link. Reflectors for conferences with a large number of participants can be run successfully on fast local networks, but are only usable across the Internet if the reflector site has high bandwidth connectivity.
It is essential that all participants in a conference, even if they have full-duplex audio hardware, operate in push-to-talk or Voice Activation (VOX or squelch) mode whilst connected to the reflector. Transmitting continuously, as can be done on a full-duplex connection, will flood the reflector with packets and disrupt the transmissions of others. As is the case with half-duplex point-to-point connections, it's a good idea for all participants in a conference to verbally indicate the end of a transmission by saying ``over'' or the equivalent.
Connections to reflector sites should use Speak Freely protocol exclusively, not RTP or VAT. sfspeaker assumes a given sender will use only one protocol at a time. Since the reflector is considered a single connection, sfspeaker has no way to determine the correct protocol if it receives an intermixed stream of packets in various protocols. Using the default Speak Freely protocol guarantees participants in the conference will be able to hear packets from all senders.
sfreflect relays packets in a variety of compression schemes without difficulty, and sfspeaker will decompress them with the appropriate algorithms and play them properly. If, however, a given compression scheme overloads the network bandwidth or CPU capacity of one or more participants in the conference, they will hear garbled audio even though others may receive the same transmission perfectly. When setting up a conference, it's best to specify a recommended compression mode appropriate to the computers and connectivity of the expected participants and urge them to adopt that mode.
sfreflect correctly forwards encrypted packets. As long as all participants in a conference have received and supply the correct key, they can communicate secure against eavesdropping by others who may connect but do not know the conference key. The automatic key generation and exchange using PGP (-z option on sfmike) cannot be used in a conference, as it is strictly a two-party transaction. Instead, distribute keys to participants in advance by electronic mail encrypted with PGP.
Like all the other components of Speak Freely, sfreflect is intended for communication among cooperating individuals. sfreflect contains no ``social engineering'' mechanisms to deter or prevent abuse. Users connected to the reflector can interrupt one another just as they can in a conference room, and a user who transmits incessantly can disrupt the proceedings as effectively as a heckler in an auditorium. One can easily envisage a variety of technological fixes which would minimise the impact of this kind of behaviour; indeed, systems intended for general public access have incorporated them for many years. sfreflect is neither intended nor recommended for open access ``chat'' applications. It can, if adequate bandwidth is available and participants understand the constraints of the medium and cooperate with one another, permit small conferences where people can come and go as they like without any central administration other than a machine running sfreflect.
Many potential users of
sfreflect
may not have the luxury of a machine to dedicate to it.
sfreflect's
``monitor host'' facility
(-m
option) permits hosting and participating in a
conference on a single machine. It's a little
confusing to set up, but once properly configured it will
get the job done. The fundamental problem which must
be overcome is that
sfreflect
listens and transmits on the port assigned to the
conference; users on other machines simply start
sfspeaker
and
sfmike
specifying that port, and the reflector does the rest.
But on the machine running
sfreflect,
one cannot start
sfspeaker
on the conference port because it has already been assigned
to the reflector.
To work around this, use the
-m
option on
sfreflect
and specify the local machine name (normally you can omit the
optional port specification and use the default port of
2074). You can now start a copy of
sfspeaker
which listens on that port, and connect to the conference
in the usual manner with
sfmike.
The reflector is careful never to forward audio to the
host on which it is running, and the monitor host
facility doesn't forward monitor packets from the local
machine, so you can listen to the conference without
feedback, echo, or locally duplicated packets. Here's
a concrete example of how to set everything up:
assume your machine has a host name of
``gizmo'' and you wish to host a conference on port
5214. You routinely run
sfspeaker
on the default port of 2074 for regular conversations.
So, you'd start the reflector and
sfspeaker
as follows:
sfreflect -v -p5214 -mgizmo &
sfspeaker -v &
which will copy all audio the reflector receives on port
5214 to the default port of 2074 on gizmo, where
sfspeaker
will play it. You can now join the conference with the
command:
sfmike gizmo:5214
and transmit and receive in the usual manner. If you wish
to announce the conference and/or yourself on a Look
Who's Listening server, set the environment
variables for the conference prior to starting
sfreflect
and for yourself before starting
sfspeaker.
See the ``Look Who's Listening'' section of the
sfspeaker
manual page for additional details.
John Walker WWW: http://www.fourmilab.ch/
This program is in the public domain. This software is provided ``as is'' without express or implied warranty.